Ethernet service operation, administration and maintenance (OAM) is a key component of operation, administration and maintenance for carrier Ethernet. It specifies protocols, procedures and managed objects for end to end fault detection, verification and isolation. Ethernet service OAM defines a hierarchy of up to eight OAM levels, allowing users, service providers and operators to run independent OAMs at their own level. It introduces the concept of a maintenance association (MA) that is used to monitor the integrity of a single service instance by exchanging connectivity fault management (CFM) messages. The scope of a maintenance association is determined by the management domain (MD), which describes a network region where connectivity and performance is managed. Each MA associates two or more maintenance association endpoints (MEP) and allows maintenance association intermediate points (MIP) to support fault detection and isolation.
A continuity check protocol is used for fault detection. Each MEP can periodically transmit connectivity check messages (CCM) and track CCMs received from other MEPs in the same maintenance association.
A loopback message (LBM) is used for fault verification. It is typically performed after fault detection. It can also confirm successful initiation or restoration of connectivity. Loopback messages are transmitted by operator command. The receiving MEP or MIP respond to the LBM with a unicast loopback reply (LBR).
A multicast linktrace message (LTM) is transmitted in order to perform path discovery and fault isolation. The LTM is transmitted by operator command. The intercepting MEP or MIP sends a unicast linktrace reply (LTR) to the originator of the LTM. The originating MEP collects the LTRs and provides sufficient information to construct the sequence of MEPs or MIPs that would be traversed by a data frame sent to the target MAC address.
There are usually two types of Ethernet service performance management: delay measurement (DM) and loss measurement (LM).
DM is performed between a pair of MEPs. It can be used for on-demand measurement of frame delay and frame delay variation. A MEP maintains the timestamp at the transmission time of ETH-DM frame.
LM is performed between a pair of MEPs, which maintain two local counters for each peer MEP and for each priority class; TxFCI: counter for data frames transmitted towards the peer MEP, RxFCI: counter for data frames received from the peer MEP. OAM frames are not counted.
There are two types of multiprotocol label switching-transport profile (MPLS-TP) OAM.
The first method is to enhance the available MPLS OAM toolset to meet the OAM requirements of MPLS-TP. Labeled switched path (LSP) ping should be extended for working without internet protocol (IP), should include tracing functionality and should support point to multipoint LSPs. For bidirectional forwarding detection (BFD), the globally unique identifier should be enabled, BFD should be enabled to work on LSP without reliance on IP/user datagram protocol (UDP) functionality and BFD should also be extended to cover point-to-multipoint LSPs.
The second method is to develop MPLS-TP OAM based on Y.1731 Ethernet service OAM. The basic idea is that Y.1731 specifies a set of OAM procedures and related packet data unit (PDU) formats that meet the transport network requirements for OAM. The actual PDU formats are technology agnostic and could be carried over different encapsulations, e.g. MPLS Generic Associated Channel.
A control protocol known as OpenFlow provides a vendor agnostic interface for controlling network forwarding elements. The essence of OpenFlow is the separation of the control plane and data plane in routing and switching gear. The interface allows flexible deployment of the network control plane software, and simplifies the control plane on network forwarding hardware. The control plane can be deployed on a centralized controller that controls multiple forwarding elements which allows increased innovation in control plane software and simplified operations and management (O&M).
In the canonical OpenFlow architecture (see FIG. 1, from Open Flow Switch Specification version 1.0), the control plane in network switching and routing equipment is moved into a separate controller 10. The controller communicates over a secure channel with the switches 11 through the OpenFlow protocol. Software running on the controller “programs” the switches with flow specifications that control the routes of packets through the network. For routing purposes, the switches only need to run an OpenFlow control plane, considerably simplifying their implementation. The architecture allows the controller to run on a separate PC and control multiple switches, rather than having a distributed control plane with components that run on each switch.
Switches are modeled as a flow table implementing e.g. firewalls, network address translation (NAT), quality of service (QoS), and to collect statistics. In the flow table, there are three columns: rules, actions, and counters. The rules column defines the flow. Rules are matched against the headers of incoming packets from network nodes 12, 13, 14, 15. If a rule matches, the actions from the action column are applied to the packet and the counters in the counter column are updated. If a packet matches multiple rules, the rule with the highest priority is applied.
The Internet has grown tremendously and the existing architecture has shown some weaknesses: the proprietary hardware design and supply, the single sourced system software supply closely coupled with equipment vendors, no application ecosystem for 3rd party innovation exists, and so on. To address all those challenges, with reference to FIG. 2, a more elaborate split network architecture concept has been proposed, where data and control plane are split and a standardized interface is built between the controller 20 and data forwarding devices 21, 22, 23.
OpenFlow is one example of a split architecture platform. It is not yet carrier-grade and needs many extensions, where one important issue is OAM. There are several split architecture OAM challenges:                Mapping traditional OAMs; i.e. how to attain a generalized Split Architecture OAM for OAM types such as Ethernet OAM, MPLS OAM, and OAM tools for IP.        The virtualization enables many operators to use the same network, i.e. a multi-carrier service OAM scenario should be supported, and further OAM automatic configuration should provided in this environment.        
The existing solutions for split architecture OAM simply copy the old OAM with static configuration. For example, again with reference to FIG. 2, to support Ethernet OAM, the Ethernet OAM modules are configured in every node 21, 22, 23. This configuration works well with Ethernet traffic flows. While split architecture (e.g. OpenFlow) can support various traffic flows such Ethernet, MPLS or IP, an Ethernet OAM is useless for monitoring an MPLS traffic flow and vice versa. The result will be different OAM configuration modules and OAM generator/parsing modules for different traffic flows. As a consequence, the complexity of data forwarding devices 21, 22, 23 will increase.